Database for check risk decisions populated with check activity data from banks of first deposit

ABSTRACT

A plurality of banks of first deposit provide checking account activity data for both transit items (checks received for deposit that need to be cleared) and incoming returns (bounced checks) to a statistical model which determines from the data the likelihood that a check from a specific checking account will be returned. This data is used to populate a database of checking accounts to be used for making check risk decisions, such as check hold policy decisions, check acceptance decisions, and open to buy decisions.

CROSS-REFERENCES TO RELATED APPLICATIONS

This application is a continuation of and claims the benefit of U.S.patent application Ser. No. 12/126,474, filed May 23, 2008, which is acontinuation of U.S. patent application Ser. No. 10/144,740, filed May14, 2002, the complete disclosures of which are incorporated herein byreference.

BACKGROUND OF THE INVENTION

Customers receive their blank checks from a payor (financial)institution. A payor institution is thus a paying financial institutionon whose account a check is drawn and by whom it is paid.

Check clearing is the process of reconciling payments among partiesassociated with a check-based financial transaction. Most checks areprocessed in the following manner: The entity to whom the check is madeout (the payee) deposits the check in his or her bank (the bank of firstdeposit or the depository bank). If the check writer's (the payor)account is in the same bank, the check is “on-us” and it is processed atthe bank. Otherwise, the physical check travels, often via a financialintermediary, to the payor's institution or bank (the paying financialinstitution or bank), and finally to the payor, who receives thecanceled checks and/or an account statement of the canceled checks on aperiodic basis, typically monthly. The checks that must travel(interbank transit checks) may be handled by multiple institutions. Ifthe payor has insufficient funds in his or her account to clear thecheck, or if the paying financial institution does not honor the checkfor other reasons, the check travels back to the bank of first depositand possibly back to the payee. The payee suffers a payment loss onchecks that do not clear.

The figures in the present specification illustrate both the prior artand the present invention depict “paper check processing.” However,there are other financial instruments, such as debit cards, electronicchecks (echecks), and Automated Clearing House (ACH) debit systemtransactions, which are ultimately tied into the checking account of apayor institution, and thus are functionally equivalent to paper checks.For simplicity, both the prior art descriptions and the presentinvention collectively refer to all of these types of financialinstruments as “checks.”

FIG. 1 shows examples of three conventional channels of check activityfor use of the customer's checks. In one channel, a customer presents acheck to a merchant to buy a product or service. The merchant, in turn,deposits the check into a “bank of first deposit,” also known as the“depository bank.” In a second channel, a customer deposits a checkdirectly into a bank of first deposit (the check may or may not be drawnon the bank of first deposit). In a third channel, the customer makes apayment to a payment processor. Like the merchant, the paymentprocessor, in turn, deposits the check into a bank of first deposit. Thebank of first deposit sends all checks (other than its own) to becleared to the Federal Reserve and/or directly to the payor institution(e.g., payor bank).

FIG. 1 of U.S. Pat. No. 5,175,682 (Higashiyama et al.) and thecorresponding description on column 1 of this patent provides a generaloverview of one conventional check clearing process for the merchantchannel discussed above. In FIG. 1, the merchant bank 103 is the bank offirst deposit, and the issuing bank 106 is the payor institution thatissued the customer a checking account on which check 101 is drawn.

A “return item” is a check that is returned unpaid by the paying (payor)institution to the bank of first deposit, usually for insufficientfunds. These bounced checks are reported back to the bank of firstdeposit in a “returns file.” FIG. 2 of the present specificationillustrates FIG. 1 of U.S. Pat. No. 5,175,682 appended to show returnsbeing sent by the issuing bank 106 to the merchant bank 103. A similarflow of returns occur in FIG. 1 of the present specification. (Returnitems that flow out of the payor institution are referred to as“outgoing returns,” whereas return items that are received by a bank offirst deposit are referred to as “incoming returns.”)

FIGS. 1 and 2 of the present specification also shows a prior art checkrisk decision process associated with a risk assessment service. Amerchant, bank of first deposit, or payment processor may subscribe to aservice that assesses the risk that a check will be returned on anaccount based on checking account status and item level data provided bythe payor institution. This may be done immediately or in an overnightbatch process.

The risk assessment service maintains a single “participant database” 10(shown in separate blocks in FIG. 1 for each channel for ease ofillustration) which is populated on a daily basis with the checkingaccount status and item level data of accounts at certain payorinstitutions (i.e., the participants) that belong to a member service ormember network. FIG. 2 also shows the role of the participant database10.

FIG. 3 shows that the prior art participant database 10 is populated bya daily flow of checking account status and item level data from each ofthe participant payor institutions. Some examples of a checking accountstatus data are provided below (meaning of the status is noted inparenthesis where needed for a full understanding):

-   -   PRESENT (balance is greater than zero)    -   NEW ACCOUNT    -   CLOSED    -   NSF STATUS (balance is less than zero)

Some examples of item level data are provided below:

-   -   STOP PAYMENTS    -   EARLY OUTGOING RETURN NOTICES

Depending upon the information in the participant database 10, alongwith other pieces of key information such as the depositor's currentbalance, number of returns, past experience, a depository bank orinstitution may place an extended hold on the deposit if there is reasonto doubt collectability. In the payment world, a payment processor mayuse this information to make a decision regarding whether or not to openthe line of credit or “open to buy” until the check clears. A merchantmay also use the information to decline to accept the check. Theparticipant database is a highly reliable source of data because it ispopulated with actual checking account status and item level datareceived directly from the payor institutions. Accordingly, merchants,banks of first deposit, and payment processors can make accurate checkrisk decisions (e.g., check acceptance decisions and check holddecisions). Primary Payment Systems, Inc. (PPS), Scottsdale, Ariz.,provides advance notice of potential check returns to inquiringcustomers using the participant database described herein.

One significant deficiency with the conventional schemes described aboveis that not all payor institutions belong to (i.e., are members of) therisk assessment service that maintains the participant database, andthus not all checking accounts have checking account status and itemlevel data present in the participant database. If a check is presentedfrom an account of a non-participating payor institution, then themerchant, bank of first deposit, or payment processor must rely on othersources of data to make a check risk decision, such as calling the payorinstitution directly, using other check verification services thatobtain data from other sources, or reviewing past check history recordsfor the customer that is presenting the check or the account that thecheck is drawn on. Entities that accept checks, and which already useservices such as those provided by PPS, would like to rely upon a betterand more accurate source of data when determining the likelihood that acheck from a specific checking account that is not in the participantdatabase will be returned so that better and more accurate check riskdecisions can be made.

Check verification services currently used by merchants, banks and thelike in making check acceptance decisions have many deficiencies. Someof the deficiencies are discussed below:

1. Services that use “negative file” databases which contain checkingaccount numbers that are known to be closed or delinquent are typicallybased on return experiences from selected merchants, and thus arelimited in scope and may become stale or outdated.

2. Retail merchants, financial institutions, check cashing services,check printing companies, collection agencies, and government agenciesroutinely report incoming returns (e.g., bounced checks), closedaccounts, new check orders, and the like to private services, who, inturn, use this information in developing proprietary databases such asnegative files for check verification. However, the vast majority ofchecking account activity data consists of checks that clear with noproblems. The proprietary databases either do not capture such activitydata, or they capture it from sources that are limited in scope (e.g.,selected merchants as described in the previous paragraph). Incomingreturn data has much better meaning when combined with transit itemswhich include therein checks that will ultimately clear with no problem.Consider, for example, a checking account holder who writes 100 checksin one year, averaging $40.00, but then accidentally bounces one $15.00check during the course of the year. Many existing check verificationservices will flag the account as a problem account due to the bouncedcheck, when, in fact, the likelihood of a check clearing on the accountis extremely high.

3. Some check verification services use predictive models based onmultiple variables to determine the level of risk associated with aparticular check transaction. However, the predictive models may nottake into account actual check activity behavior of the check presentingcustomer. Thus, a customer who has a stellar check activity record mightfit a profile of a bad check writer and be negatively treated as aresult of the profile which may not even factor in actual checkactivity. U.S. Pat. No. 5,679,93 8 (Templeton et al.) describes the useof a typical predictive modeling system.

4. Conventional check verification databases that are built fromretailer (merchant) check activity data inherently miss a largepercentage of checking accounts that are rarely, if ever, used forconsumer-type purchases. Furthermore, a large percentage of retailers donot subscribe to, or report check activity to, a check acceptanceservice, and thus the databases do not contain a complete picture of thecheck writing activity of the checking accounts that even make it intothe databases. Positive files (positive databases), negative files(negative databases) and velocity/risk databases, which are typicallycreated by check acceptance services used by retailers, suffer fromthese deficiencies. Even the largest commercially available servicestoday have no checking account activity data on about half or more ofactive checking accounts.

Despite the multitude of existing check verification and acceptanceservices, there is still an unmet need for a service that can be used tomake statistically significant check risk decisions based at least inpart on actual checking account activity data for a greater percentageof active checking accounts, and which can be used with confidence bymerchants, banks and payment processors alike. The present inventionfulfills such a need.

BRIEF SUMMARY OF THE INVENTION

One preferred embodiment of the present invention provides acomputer-implemented process which populates a database of checkingaccount with statistical data regarding the likelihood that a check froma specific checking account will be returned. The process includes atleast the following steps:

1. Receive checking account activity data directly from a plurality ofbanks of first deposit. The checking account activity data includestransit items and incoming returns.

2. Analyze the checking account activity data using a statistical modelto determine the likelihood that a check from a specific checkingaccount will be returned. As part of the analysis, it is firstdetermined if there is enough checking account activity data for aspecific checking account number to make a statistically significantdetermination of the likelihood that a check from a specific checkingaccount will be returned. If so, then the database is populated withchecking account data for that checking account number. If not, then thechecking account data for that specific checking account number isplaced in a hold queue.

3. Populate a database with checking account data, including checkingaccount numbers, and likelihood that a check from a specific checkingaccount number will be returned.

4. Periodically, repeat steps 1 and 2 with new checking account activitydata and update the database of checking account data with the newchecking account activity data. As part of the periodic review, thechecking account data for any checking account numbers in the hold queueare reviewed to determine if the new data provides enough checkingaccount activity data to make a statistically significant determinationof the likelihood that a check from a specific checking account will bereturned. If so, then the database is populated with those checkingaccount numbers and they are removed from the hold queue.

In another preferred embodiment of the present invention, check riskdecisions are made using the database. Checking account data of a checkpresented for deposit, payment or clearing is received, and theinformation in the database is used to make a check risk decision.

In yet another preferred embodiment of the present invention, acomputer-implemented process is provided for making a check riskdecision using a first database populated with checking account statusand item level data from checking accounts of payor institutions thatbelong to a member service, and a second database that is populated withchecking account data of checking accounts that are not held by payorinstitutions that belong to the member service. The second databaseincludes checking account numbers and likelihood that a check from aspecific checking account number will be returned as determined by astatistical model. The second database is populated by checking accountactivity data, including item files and incoming returns, receiveddirectly from a plurality of banks of first deposit. The inquiry processincludes at least the following steps:

1. Inquirer submits account number and routing and transit data of apresented check.

2. Use the first database to make a check risk decision for checkingaccounts of payor institutions that belong to the member service.

3. Use the second database to make a check risk decision for checkingaccounts that are not held by payor institutions that belong to themember service.

In one preferred implementation of the embodiments described above, thechecking account activity data is received solely from a plurality ofbanks of first deposit, and the check risk decision is a checkacceptance decision, a check hold policy decision, or an open to buydecision. The item level data in the first database may include stoppayments and early outgoing return notices.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing summary, as well as the following detailed description ofpreferred embodiments of the invention, will be better understood whenread in conjunction with the appended drawings. For the purpose ofillustrating the invention, there is shown in the drawings embodimentswhich are presently preferred. It should be understood, however, thatthe invention is not limited to the precise arrangements andinstrumentalities shown.

In the drawings:

FIGS. 1-3 are schematic block diagrams of conventional check riskdecision and check clearing processes;

FIG. 4-5 are schematic block diagrams of check risk decision and checkclearing processes in accordance with the present invention;

FIG. 6 is a flowchart of the process shown in FIG. 5;

FIG. 7 shows a block diagram of one suitable scoring model process foruse in one preferred embodiment of the present invention; and

FIGS. 8-12 show how to populate and maintain the non-participantdatabase.

DETAILED DESCRIPTION OF THE INVENTION

Certain terminology is used herein for convenience only and is not to betaken as a limitation on the present invention. In the drawings, thesame reference letters are employed for designating the same elementsthroughout the several figures.

1. Overview of Present Invention

Banks of First Deposit receive incoming returns on a daily basis forchecks that they previously submitted for clearing. The checking accountdata from the incoming returns are received in “incoming returns files.”(No “early notice returns” are included in these files.) Each businessday, Banks of First Deposit also receive a large volume of checks thatthey accept for deposit from merchants, consumers, small businesses,corporations, and payment processors. These checks are sent forclearing, typically on a daily basis. (“On us” checks are cleared withinthe bank.) The checks that the Banks of First Deposit receive and whichmust be cleared are “transit items,” as discussed above. Checkingaccount data from the daily transit items are consolidated into “transititem files.” The present invention taps the rich source of informationcontained in the incoming returns files and the transit item files, andthen uses the information to create a “non-participant database” thatcan work alongside of the existing participant database, or as astand-alone database. In this manner, merchants, banks, and paymentprocessors can further reduce payment losses from bad checks.

FIG. 4 shows how financial institution data from banks of first deposit12 are to be used. The banks transmit their transit item files(including checks to be cleared) and incoming returns files (includingbounced checks) on a daily basis to a non-participant databasemanagement entity 14. This entity removes participant data via filter 16since that data is already collected and accounted for in theconventional participant database scheme.

Transit item files contain the MICR line data including the routing andtransit number, account number, tran code or its equivalent ifapplicable, serial number (check number), dollar amount and date.Incoming returns contain the routing and transit number, account number,tran code or its equivalent if applicable, serial number (check number),date and reason(s) for return.

The non-participant data is applied to a statistical model 18 (also,referred to as a “scoring model”) which uses statistical analysis todetermine the likelihood that a check from a specific non-participantchecking account will return (i.e., not clear). The results of thestatistical model are used to populate a non-participant database 20. Ifthere is insufficient data about a checking account to make a validdetermination, then the data is sent to a hold queue 22. As additionaldata arrives for a checking account that is in the hold queue 22, thehold data is reapplied to the statistical model 18. The additional datais also used in association with a historical queue 24 to make freshdeterminations of the likelihood of clearing for checking accounts thatare in the non-participant database 20. That is, the statistical model18 is periodically rerun using fresh data, and the non-participantdatabase 20 is updated with new scores. Over time, many of the accountsin the hold queue 22 should migrate to the nonparticipant database 20.Eventually, the non-participant database 20 will include likelihood datafor most of the non-participant checking accounts.

In the preferred embodiment of the present invention, any new checkingaccount numbers that pass through the filter 16 and which are notalready in the non-participant database 20 are added to thenon-participant database 20, even if no likelihood data is available dueto the inability to make a valid determination. These checking accountnumbers are flagged and stored in the hold queue 22. These accounts arenot scored. In an alternative embodiment, unscoreable checking accountnumbers are not entered into the non-participant database 20.

FIG. 5 is similar to FIG. 2, except that FIG. 5 shows thenon-participant database 20 working alongside the participant database10. A merchant (or alternatively, a merchant processor or checkacceptance company), depository bank (or alternatively, a depositorybank processor), or payment processor evaluates the risk of the check byusing the participant data via the participant database processdescribed in FIG. 1. However, checks from a non-participant checkingaccount are run against the accounts in the non-participant database 20.If the checking account is in the non-participant database and theinquirer is satisfied with the level of risk associated with theaccount, as indicated by a score, then the inquirer will accept thecheck and/or apply any appropriate hold policies to the check.Alternatively, the inquirer may also combine the score from thenon-participant database 20 with other information about the checkpresenter in making check acceptance and/or check hold decisions. If thechecking account of the presented check does not appear in eitherdatabase 10 or 20, or if the checking account of the presented checkappears in the database 20 with an unscoreable indicator, then theinquirer will use other information to evaluate the risk of the check.

FIG. 6 is a flowchart of the process shown in FIG. 5. The process beginswhen an entity makes an inquiry regarding one or more checking accountnumbers. The inquiry may be part of a batch process or a real timeprocess. The inquiry generates a hit report with scores for each hit,and, in some instances, up to five reason codes for the score. Reasoncode(s) are included only for certain types of inquiries from certainentities.

A real time inquiry can be made by swiping a check with a MICR readingdevice. There are numerous MICR capture devices, including, but notlimited to, dial-up MICR readers which directly access a database (e.g.,PPS's database), and integrated online services which connect throughmerchants or teller windows. In one preferred embodiment, the checkreader dials into a database containing the databases 10 and 20, andreceives a response therefrom. Responses from the database 20 includethe score data, and, optionally, reason codes(s) if any exist.

If an account is not in the database, the requester is informed of thisfact. In one alternative embodiment, this step occurs only for real timeinquiries and is not performed for batch inquiries. The remaining stepsin the process shown in FIG. 6 are self-explanatory.

One important feature of the present invention is that thenon-participant database 20 is built from all transit item files andincoming returns files supplied by banks of first deposit 12. In onepreferred embodiment of the present invention, the non-participantdatabase is built solely from such data. Banks of first deposit are areliable, current, comprehensive, and broad-based source of checkingaccount activity data, and thus are an ideal candidate for building thenon-participant database. Building the non-participant database 20 fromtransit item files and incoming returns files supplied by banks of firstdeposit provide significant advantages over conventional approaches tobuilding check acceptance/verification databases, such as positivedatabases, negative databases and velocity/risk databases. For example,banks of first deposit receive checks from all types of checkingaccounts (e.g., individual household accounts, commercial/businessaccounts, institutional accounts), and thus capture data fromsignificantly more accounts and for significantly more types of paymentsthan services that capture only merchant-based checking activity. Thenon-participant database 20 is updated on a nightly basis as checks aredeposited and as checks are returned. The data is therefore very currentand accurate. Furthermore, incoming returns are received by thenon-participant database 20 before the merchant receives them, sincereturns are sent first to the depository bank and then to the merchant.Thus, databases that are built from merchant-reported returns will notbe as current as the returns logged into the non-participant database20.

One useful application of the present invention is to allow entitiesthat accept checks to make check hold decisions that are more accuratelytailored to the likely risk of a check being returned. The FederalReserve Board specifies the rules for check holds in Regulation CC,Availability of Funds and Collection of Checks.

Based on the government regulations for hold policies, a largepercentage of checks fall into one or more categories that permit a holdgreater than one business day, and thus there will be discretion in thehold policy, particularly for deposits eligible for exception holds. Infact, the very existence of a statistically created database thatpredicts the likelihood of a particular check being returned allowsentities that receive checks for payment or clearing to legitimatelyclassify a check as being eligible for exception holds, and thus alonger hold period.

In an alternative embodiment of the present invention, the participantdatabase 10 and non-participant database 20 are used in the followingmanner to prevent and reduce losses by payment processors, such ascredit card companies:

1. A credit card payment is made by check.

2. The check is submitted to the credit card company for payment.

3. The payment processor uses a service such as PPS's PRIME CHEK® toverify the status of the account if it is in the participant database10, or the likelihood of a return if it is in the non-participantdatabase 20. Depending upon the status or risk of the account, thecredit card company makes a decision to place an extended hold on theline of credit until the check actually clears. This protects the creditcard company from opening the line of credit to buy before the checkclears, thereby preventing customers from implementing “bust out”schemes. The non-participant database 20 significantly expands thenumber of accounts that can be checked in this manner.

2. Detailed Description

FIG. 7 shows a block diagram of one suitable scoring model process foruse in one preferred embodiment of the present invention. The scoringmodel has a plurality of weighting factors. The actual weighting factorsmay differ based on fine-tuning and honing of the scoring model, andwill change over time. Scoring models are usually proprietary.

However, the process for creating a scoring model is well-known. Data iscollected and then statistically reviewed to identify patterns of eventswhich predict an outcome. The predictive characteristics are identifiedand then built into a model.

In alternative embodiments of the present invention, neural models orrules models may be used instead of statistical models and the scope ofthe present invention includes such variations.

FIGS. 8-12 describe how to populate and maintain the non-participantdatabase 20 (NPDB) by showing how a very small set of sample data isprocessed.

FIG. 8 shows how data is contributed to the NPDB. The contributor (bankof first deposit) sends its transit item files and incoming returnsfiles. As described above, transit item files contain the MICR line dataincluding the routing and transit number (R&T), account number, trancode or its equivalent if applicable, serial number (check number),dollar amount and date. Incoming returns contain the routing and transitnumber, account number, tran code or its equivalent if applicable,serial number (check number), date and reason(s) for return. Forsimplicity, FIG. 8 shows only some of these fields.

The routing and transit number of each transit item and incoming returnis used to identify participant and non-participant accounts. Thisnon-participant account data is filtered and sent to the NPDB. FIG. 8shows five entries from a transit item file. Three entries belong toparticipants and thus are dropped. The remaining two entries arenon-participant accounts and thus are kept. FIG. 8 also shows twoentries from an incoming returns file. One entry belongs to aparticipant and thus is dropped. The other entry is a non-participantaccount and is kept.

FIG. 9 shows how inquiries are made to the respective participantdatabase and NPDB by a customer of the system (e.g., bank, merchant,payment processor). In this example, the inquiry is a batch mode inquiryon a transit item file made before the checks in the file are sent forclearing, and is being made to determine the hold policy to apply toeach of the checks. (The bank has already accepted the checks fordeposit.) For simplicity, the accounts in the transit item file are thesame as the accounts in the transit item file shown in FIG. 8. Thetransit item file in FIG. 9 was created shortly after the transit itemfile in FIG. 8, and thus the check numbers are higher in the FIG. 9file.

Referring to FIG. 9, the routing and transit number of each transit itemis used to identify participant and non-participant accounts. Theparticipant transit items are sent to the participant database 10 formatching against accounts and creation of a first hit report file. Thehold policy of each check is then decided based on the checking accountstatus and item level data stored therein. Each bank may have its ownrules regarding how checking account status and item level data are usedto set the hold policy or any other check risk decision. Thenonparticipant transit items are sent to the non-participant database 20for matching against accounts and creation of a second hit report file.The hold policy of each check is then decided based on the likelihood ofclearing score, if one exists. Again, each bank may have its own rulesregarding how a risk score is used to set the hold policy or any othercheck risk decision.

FIG. 10 shows non-participant checking account activity data stored inthe historical queue 24 and the actual data stored in the NPDB. Thehistorical queue 24 stores all transaction history data. As new data iscontributed, the historical queue 24 is updated. The data in thehistorical queue is periodically fed to the statistical model whichscores the accounts based on the historical transactions. Each accountreceives a score which is placed in the NPDB, as well as one or morereason codes that relate to the determination of the score. Good scoresand bad scores may have reason codes.

FIG. 10 shows transaction data for four checking accounts. In thisexample, three or more transactions were deemed to be sufficient to makea statistically significant determination of the likelihood that a checkfrom a specific account will be returned. The first account has fourtransactions, and the last three transactions were returned. Thisaccount receives the highest score (highest risk of a subsequenttransaction not clearing). The second account has three transactions,all of which cleared. This account received a low score. The thirdaccount also has three transactions, but the most recent transaction wasa return for insufficient funds. Accordingly, this account received arelatively high score. The fourth account has only one transaction andthus no score was developed for this account. The transaction data forthe fourth account is also placed in the hold queue, and is moved out ofthe hold queue if, or when, a sufficient amount of transaction databecomes available to score the account.

FIG. 11 shows the rescoring process for one account. As new transactiondata becomes available for an account, it is added to the historicalqueue 24 and the account is rescored. The new score replaces the oldscore. Once the account is rescored, the account is updated on a nightlybasis by the system. In FIG. 11, one new transactions appeared foraccount number 164456 in the latest daily update. The new transaction isanother return for insufficient funds. Accordingly, the score for thisaccount is increased from 8 to 9.

In another embodiment of the present invention, the non-participantdatabase management entity 14 receives the transit item files andincoming returns files from a single entity which receives such filesfrom some or all of the banks of first deposit. The single entity may bea check processor or a check clearing entity, such as a clearinghouse orthe Federal Reserve. The Federal Reserve receives the most comprehensiveflow of data, whereas an individual check processor may receive datafrom only a small number of banks of first deposit.

FIG. 12 shows a process wherein the non-participant database managemententity 14 receives the transit item files and incoming returns filesfrom the Federal Reserve which receives such files from a plurality ofbanks of first deposit.

As discussed above, for simplicity, both the prior art descriptions andthe present invention collectively refer to financial instruments suchas debit cards, electronic checks (echecks), and Automated ClearingHouse (ACH) debit system transactions as “checks.” The scope of thepresent invention includes these other forms of financial transactionswhich are ultimately tied into the checking account of a payorinstitution, and thus are functionally equivalent to paper checks.

The present invention may be implemented with any combination ofhardware and software. If implemented as a computer-implementedapparatus, the present invention is implemented using means forperforming all of the steps and functions described above.

The present invention can be included in an article of manufacture(e.g., one or more computer program products) having, for instance,computer useable media. The media has embodied therein, for instance,computer readable program code means for providing and facilitating themechanisms of the present invention. The article of manufacture can beincluded as part of a computer system or sold separately.

It will be appreciated by those skilled in the art that changes could bemade to the embodiments described above without departing from the broadinventive concept thereof. It is understood, therefore, that thisinvention is not limited to the particular embodiments disclosed, but itis intended to cover modifications within the spirit and scope of thepresent invention as defined by the appended claims.

1. (canceled)
 2. A computer-implemented method for facilitating themaking of a risk decision, comprising: receiving and storing, at a firstdatabase system accessed by a computer, status data relating to accountsmaintained by member institutions that belong to a member service, thestatus data received from the member institutions; receiving andstoring, at a second database system accessed by the computer, accountactivity data relating to accounts of non-member institutions that donot belong to the member service, the account activity data contributedby member institutions and relating to accounts not maintained by thecontributing member institutions; filtering the activity data receivedat the second database system to remove activity data relating toaccounts maintained by member institutions, and thereby storing in thesecond database system only data relating to accounts of non-memberinstitutions that do not belong to the member service; populating thesecond database system with risk data reflecting the likelihood that atransaction conducted against a specific account will not clear, asdetermined by a risk scoring model; receiving, at the computer, accountdata relating to an account against which a transaction is conducted;using the account data, at the computer, to determine if the transactionis conducted against one of the accounts of member institutions thatbelong to the member service and to determine if the transaction isconducted against one of the accounts of non-member institutions that donot belong to the member service; accessing the first database system tomake a risk decision for accounts of member institutions that belong tothe member service; and accessing the second database system to make arisk decision for accounts of non-member institutions that do not belongto the member service.
 3. The method of claim 2, wherein the accountsare checking accounts.
 4. The method of claim 2, wherein the activitydata relates to a paper check drawn against the accounts.
 5. The methodof claim 2, wherein the activity relates to an electronic transactionagainst the accounts.
 6. The method of claim 5, wherein the electronictransaction is an automated clearinghouse (ACH) transaction.
 7. Themethod of claim 2 wherein the member service operates the first databasesystem and the second database system.
 8. The method of claim 7, whereinmember institutions subscribe to the service in order to access thestatus data stored in the first database system relating to accounts ofmember institutions, and access risk data in the second database systemrelating to accounts of non-member institutions.
 9. The method of claim2, wherein the risk decision is a check acceptance decision.
 10. Themethod of claim 2, wherein the risk decision is a check hold policydecision.
 11. The method of claim 2, wherein the risk decision is anopen to buy decision by a payment processor, pending a check clearing.12. The method of claim 2, wherein the risk data comprises a scorerelating to the likelihood of a transaction against an account notclearing, and wherein the method further comprises determining the scoreby the risk scoring model using the account activity data received atthe second database system.
 13. A system for facilitating a riskdecision, comprising: one or more processors; and a memory storinginstructions that are executed by the one or more processors andconfigure the system to: receive and store, at a first database system,status data relating to accounts maintained by member institutions thatbelong to a member service, the status data received from the memberinstitutions; receive and store, at a second database system, accountactivity data relating to checking accounts of non-member institutionsthat do not belong to the member service, the account activity datacontributed by member institutions and relating to accounts notmaintained by the contributing member institutions; filter the activitydata received at the second database system to remove activity datarelating to accounts maintained by member institutions, and therebystoring in the second database system only data relating to accounts ofnon-member institutions that do not belong to the member service;populate the second database system with risk data reflecting thelikelihood that a transaction conducted against a specific account willnot clear, as determined by a risk scoring model; receive, at thecomputer, account data relating to an account against which atransaction is conducted; use the account data, at the computer, todetermine if the transaction is conducted against one of the accounts ofmember institutions that belong to the member service and to determineif the transaction is conducted against one of the accounts ofnon-member institutions that do not belong to the member service; accessthe first database system to make a risk decision for accounts of memberinstitutions that belong to the member service; and access the seconddatabase system to make a risk decision for accounts of non-memberinstitutions that do not belong to the member service
 14. The system ofclaim 13, wherein the accounts are checking accounts.
 15. The system ofclaim 13, wherein the activity data relates to a paper check drawnagainst the accounts.
 16. The system of claim 13, wherein the activityrelates to an electronic transaction against the accounts.
 17. Thesystem of claim 16, wherein the electronic transaction is an automatedclearinghouse (ACH) transaction.
 18. The system of claim 13 wherein themember service operates the first database system and the seconddatabase system.
 19. The system of claim 18, wherein member institutionssubscribe to the service in order to access the status data stored inthe first database system relating to accounts of member institutions,and access risk data in the second database system relating to accountsof non-member institutions.
 20. The system of claim 13, wherein the riskdecision is a check acceptance decision.
 21. The system of claim 13,wherein the risk decision is a check hold policy decision.
 22. Thesystem of claim 13, wherein the risk decision is an open to buy decisionby a payment processor, pending a check clearing.
 23. The system ofclaim 13, wherein the risk data comprises a score relating to thelikelihood of a transaction against an account not clearing, and whereinthe instructions that are executed by the one or more processors furtherconfigure the system to: determine the score by the risk scoring modelusing the account activity data received at the second database system.